Аналитическая компания Gartner опубликовала магический квадрант (Magic Quadrant) за 2017 год, посвященный публичным облачным сервисам, предоставляющим ресурсы инфраструктуры как услугу ( IaaS, Infrastructure-as-a-Service). Напомним, что о квадранте по серверной виртуализации мы писали вот тут.
Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
Для сравнения посмотрим на квадрант по IaaS, опубликованный в августе 2016 года:
Как видно из сравнения двух квадрантов, в 2017 году впервые появилась компания Oracle со своим публичным облаком (мы писали об этом вот тут). Кроме того, в нем появилось облако Alibaba Cloud от всем известного китайского торгового гиганта.
Кстати, обратите внимание, что количество компаний в квадранте увеличилось с 10 до 14 - это хороший знак для публичных облаков: новые игроки выходят на рынок, что развивает здоровую конкуренцию и улучшает ввиду этого качество предоставляемых услуг.
Те из вас, кто следят за обновлениями решения для организации кластеров хранилищ VMware vSAN, знают, что в версии vSAN 6.6 появилась возможность обеспечивать избыточность на уровне локального сайта и на уровне двух площадок растянутого кластера (stretched cluster) в то же самое время.
Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).
Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен. Ну и, само собой, при отказах дисков/хостов внутри площадки виртуальные машины также будут защищены в соответствии с политикой SFTT.
Все это вызывает логичный вопрос - а как планировать емкость обеих площадок, на которых работает vSAN? Кстати, нельзя называть эти площадки основной и резервной, так как они работают в режиме Active-Active.
Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.
Учитывая все это, в VMware сделали единую табличку, которая поможет вам при планировании емкостей инфраструктуры vSAN как для растянутого кластера, так и для кластера в рамках одной площадки:
В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.
SFTT определяет число отказов дисковых объектов внутри площадки, которое сможет перенести каждая из площадок вашего растянутого кластера.
Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).
Ну а если вы будете использовать обычные диски и защиту Mirroring как внутри площадки, так и между площадками - вам потребуется 400% исходной емкости.
В довершение нужно обязательно отметить, что администратор не может контролировать, где будут размещаться дисковые объекты ВМ в пределах одного сайта (то есть не получится обеспечить распределение дублированных копий объектов на уровне серверных стоек одной площадки).
Последний пункт как раз и заслуживает внимания. В состав vCenter Server 6.5b вошел vSphere Client версии 6.5 (Build 5178943). Судя по версии билда - это нечто среднее между vSphere Client 3.7 (Build 5168275) и vSphere Client 3.8 (Build 5204615), которые доступны на сайте проекта VMware Labs. То есть, это практически самый свежий клиент.
Тем не менее, у vSphere Client 6.5 на сегодняшний день отсутствует следующая функциональность (подробнее тут):
Функциональная область
Рабочий процесс / возможность
Не поддерживается в vSphere Client
Cluster
Configuration
DRS/HA virtual machine overrides
Proactive HA
Cluster
Datastore
Configure SDRS rules and VM overrides
Cluster
Monitor
Overview performance charts
Content Library
Deploy from template
Advanced deploy options
Advanced networking template customization
Datastore
Management
Datastore default policy read-only view
Create NFS 4.1 with Kerberos authentication
Create VVOL datastore wizard
VVOL datastore default profiles
VVOL capability profiles capacity summary portlet
Mount and unmount existing VVOL datastore to hosts
Import and export distributed switch and distributed port group
Manage physical network adapters for distributed switch
Fault Tolerance
Displays and Operations
Fault tolerance operations
Fault tolerance summary portlet
Migrate secondary workflow
Host Management
Host Configuration
ESXi two-factor authentication
Configure host profiles
Host Management
Network Configuration
Health checks
Edit TCP/IP stacks
Migrate VMs to another network
Host Management
Settings
Host VVOL protocol endpoints
Host Management
Storage Devices
Erase partition
Turn locator LED on and off
Mark and unmark flash disk
Host Management
Storage Policy
Global view
Summary view
Monitor view
Manage view
Related items view
VM storage policy assignments read-only view
Create and edit storage policy wizard
Integrate storage policies in deploy OVF wizard
Storage policy delete, check compliance, and reapply
Reset VSAN default policy
Delete storage policy component
Host Storage
iSCSI
Hardware iSCSI to IPv6 support
Edit advanced options
Host Storage
Management
Edit host cache configuration
Protocol endpoint properties, paths, and datastores
I/O filters
Host Storage
Virtual Flash
Resource management
Host swap cache configuration
Add virtual flash resource capacity
Performance Charts
Advanced
Select full range of metrics in advanced performance charts
Performance Charts
Overview
View overview performance charts
Select full range of metrics in advanced performance charts
Platform
508 Compliance
Initial support
Platform
Actions
Action button bar
Platform
Advanced search
Search for VMs by compliance status
Platform
Docking
Drag and drop, close, and restore panes
Platform
Inventory Tree
Drag and drop
Inline rename
Aggregated nodes
Platform
Live Refresh
Object navigator live refresh
Related lists live refresh
Platform
Object Selector
Show recent objects
Platform
Portlets
Close portlets
Platform
Recent Objects View
View recent object pane
Platform
Related Items Lists
Action button bar
Filter list
Quick filter lists
Platform
Selection Widget
Search
Platform
Wizards
TIWO (Things I am Working On) wizard
Sticked workflows (wizard over wizard)
vApp
All edit and display settings
All workflows
VCHA
Management and Deployment
All workflows
VM Administration
Compliance
Check VM compliance
SPBM compliance column in VM list
VM Administration
Deployment
Deploy VM from content library wizard
VM Administration
Global Permissions
Read only view of global permissions details
Create permission
Edit existing role of a permission
Right click on object to add permission
VM Administration
Profiles
Manage VM profiles (including RGs)
Batch manage VM profiles
VM Administration
Single Sign-on
SSO users and groups
SSO configuration
VM Administration
Storage Policies
Reapply storage policies for out-of-date VMs
Storage policy components view
Create and edit storage policy component dialog
Delete storage policy component
VM Administration
Summary
VM compliance summary portlet
VM Configuration
VM Edit Settings
Device configuration options
Adding the hardware devices: exist hard disk, RDM disk, floppy drive, serial port, parallel port, host USB device, USB controller, SCSi device, PCI device, SATA controller
SDRS rules
vApp options
Boot options power management
Edit advanced settings
Remote console options
Fibre channel NPIV
VM Configuration
VM Summary
Advanced configuration portlet
Virtual machine storage policies portlet
vApp details portlet
Update manager compliance portlet
Video card details in hardware portlet
VM Crypt
All
All workflows
VM Customization
Image Customization
All workflows
VM Deployment
Deploy OVF/OVA
Advanced storage
Advanced networking
Customize template
VM Lists
VMs
VM list on vApp
Sorting and filtering by column
VM Migration
Drag & Drop
Tree to list
To and from datastore and datastore cluster
To and from standard network, opaque network, or distributed port group
VM Migration
Migrate VM
Migration of compute and storage
Migration to another VMware vCenter cluster
Migration of multiple virtual machines at once
VM Migration
Move To
All workflows
VM Operations
Remote Console
Changing preferred console from the gear icon
VM Provisioning
New VM
Missing devices for hardware customization
VM Provisioning
Register VM
UI validations
Customize text on page when registering VM template
VM Snapshot
Snapshot Operations
Скачать VMware vCenter Server 6.5b можно по этой ссылке, а Release Notes доступны тут.
Кроме того были выпущены обновления следующих продуктов:
Как некоторые знают, в VMware vSphere 6.5 появилась (а точнее вернулась снова) возможность Automatic VMFS UNMAP - возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически. Работает UNMAP только для "тонких" (Thin Provisioned) LUN, на которых размещаются тома VMFS.
Из GUI vSphere Web Client можно управлять только UNMAP'ом для томов VMFS 6, для пятой версии файловой системы это нужно делать вручную с помощью ESXCLI. Кроме того, механизм UNMAP работает в асинхронном режиме, а иногда хочется почистить хранилища от неиспользуемых блоков прямо сейчас.
Поэтому весьма кстати, что на сайте EnterpriseDaddy обнаружился полезный PowerCLI-скрипт, который возвращает дисковое пространство в LUN для заданного хранилища хоста ESXi.
Эта функция принимает на вход имя хоста ESXi и Datastore, а также отключает таймаут на исполнение операций, так как возврат дискового пространства LUN может занять часы.
Function Perform-VMFSUnmap {
[CmdletBinding()]
param(
[Parameter(
Mandatory=$true)]
[String[]]$Datastore,
[String]$ESXiHost
)
Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1 -Scope Session -Confirm:$false
$ESXHost = Get-VMHost $ESXiHost
$DatastoreName = Get-Datastore $Datastore
Write-Host 'Using ESXCLI and connecting to $VMHost' -ForegroundColor Green
$esxcli = Get-EsxCli -VMHost $ESXHost
Write-Host 'Unmapping $Datastore on $VMHost' -ForegroundColor Green
$esxcli.storage.vmfs.unmap($null,$DatastoreName,$null)
}
Компания Citrix на днях объявила о доступности для загрузки новой версии своей платформы виртуализации Citrix XenServer 7.1. Напомним, что прошлая версия продукта - XenServer 7 - была выпущена в мае прошлого года.
Давайте посмотрим на возможности нового XenServer 7.1:
Ускорение загрузки виртуальных машин до 25% за счет применения технологии Provisioning Services (PVS) Accelerator. В некоторых случаях это приводит к сокращению передаваемого трафика в сети на величину до 98% и уменьшению нагрузки на CPU до 93%. Эта фича доступна только для пользователей издания Platinum продукта XenApp и для любого издания XenDesktop.
XenServer перешел на условия поставки Long Term Service Release (LTSR), что предполагает 10-летний цикл сопровождения продукта (5 лет поддержки и еще 5 лет расширенной поддержки). Такие же условия сейчас предлагаются для XenApp и XenDesktop.
Для всех пользователей продуктов XenApp и XenDesktop платформа XenServer Enterprise доступна бесплатно, вне зависимости от типа лицензии. Это предполагает наличие такой важной фичи, как кэширование в памяти на чтение, что улучшает производительность Machine Creation Services (MCS).
Специальные преимущества для пользователей решений Nutanix: улучшенные provisioning services, поддержка NVIDIA GRID vGPU, расширенная поддержка XenServer Direct Inspect APIs.
Интересная штука - live-патчинг хостов XenServer, не требующий их перезагрузки. Такого нет даже у VMware!
Автоматические обновления хостов XenServer без участия администратора.
Средство миграции XenServer Conversion Manager теперь позволяет переносить Linux-машины с платформы VMware vSphere на XenServer.
Полноценные возможности анализа трафика и предотвращения вторжений XenServer Direct Inspect APIs совместно с технологией Bitdefender Hypervisor Introspection. Это также доступно и для XenServer 7.0.
Если у вас есть какое-либо издание Citrix XenDesktop прошлых лет, вы можете использовать и XenServer 7.1 бесплатно! Ну а сравнение изданий XenServer 7.1 можно посмотреть по этой ссылке. Скачать же 90-дневную пробную версию платформы можно вот тут. Документация доступна здесь.
Вебинар пройдет 9 февраля в 19-00 по московскому времени.
Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
Помимо этого, LSFS имеет следующие полезные функции:
Встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут).
Поддержка непрерывной дефрагментации (она идет в фоне).
Дедупликация данных "на лету" (то есть, перед записью на диск).
Улучшения производительности за счет комбинирования операций записи.
Поддержка overprovisioning.
Использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов.
В новом билде StarWind Virtual SAN у LSFS появилось несколько новых экспериментальных возможностей, которые позволят вам получить больше от этой технологии:
Передача операций по работе с метаданными на SSD (что снижает требования к RAM).
Оптимизация производительности операций чтения и записи, что сокращает время на них до 4-5 раз.
На днях компания VMware выпустила интереснейший технический документ обо всех новых возможностях новой версии своей флагманской платформы виртуализации - "What’s New in VMware vSphere 65".
Напомним, что о новых возможностях VMware vSphere 6.5 мы уже писали вот тут. Также можно посмотреть наши заметки тут, тут и тут. А вот содержание документа:
VMware vCenter Server
Migration
Improved Appliance Management
VMware vCenter High Availability
Backup and Restore
vSphere Web Client
vSphere Client
vSphere Host Lifecycle Management Enhancements
vSphere Update Manager
VMware Tools and Virtual Hardware Upgrades
Previous Windows-Based Architecture Still Offered
Host Profiles
Profile Management Improvements
Operational Enhancements
Auto Deploy
Manageability Improvements
Performance and Resiliency Enhancements
VMware Tools 10.1 and 10.0.12
Signed ISO Images
Bifurcation of VMware Tools for Legacy and Current Guests
Bundling of Tools for Most Popular Guests Only
Guest OS Granularity Increase
Detailed Display of VMware Tools Type and Version in vSphere Web Client
Improved Detection of Availability of Updated VMware Tools Installers
vSphere Operations
Operations Management
Log Monitoring
Developer and Automation Interfaces
Program Interfaces
vCenter Server Appliance API
Virtual Machine API
Discover the APIs with the New API Explorer
Process Improvements
Command-Line Interfaces
What’s New in VMware vSphere
VMware PowerCLI
Core vSphere Module
Storage Module
VMware Horizon Module
Security
Virtual Machine Encryption
Encrypted vMotion
Secure Boot Support
Virtual Machine Secure Boot
ESXi Host Secure Boot
Enhanced Logging
VM Sandboxing
Automation
vSphere 65 Availability Enhancements
Proactive HA
VMware vSphere High Availability Orchestrated Restart
Компания VMware недавно выпустила документ "Instant-Clone View Desktops in Horizon 7", который может оказаться полезным многим администраторам решения VMware Horizon View. Напомним, что технология Instant Clone (ранее она называлась VMFork) позволяет почти мгновенно создавать работающие копии виртуальных машин.
Суть этой технологии такова, что "на лету" создается клон виртуальной машины (VMX-файл и процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область.
Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ. При выключении такой виртуальной машины она полностью уничтожается из памяти и стирается с хранилища, что очень удобно для выполнения типизированных задач, приложения для которых доставляются средствами динамической сборки App Volumes (например, для оператора колл-центра).
Также сам workflow мгновенных клонов выглядит проще, чем для связанных клонов View Composer (об этом мы писали вот тут):
Аналитическая компания Gartner выпустила очередной "магический квадрант" об инфраструктуре серверной виртуализации и лидерах в этой сфере - Magic Quadrant for x86 Server Virtualization Infrastructure 2016. О квадрантах прошлых лет мы уже много писали тут и тут. Интересная деталь - если в 2014 году Gartner оценивала, что примерно 70% серверов архитектуры x86 виртуализованы, то сейчас этот показатель достигает 80%.
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
В этом году квадрант не сильно отличается от прошлого года:
Как мы видим за последний год ситуация не сильно изменилась, разве что можно отметить то, что Red Hat перешла в разряд визионеров за счет довольно широкого внедрения гипервизора KVM в архитектурах OpenStack со средствами управления OpenStack Glance project (для управления образами серверов и дисками), а также OpenStack Neutron (для управления виртуальной корпоративной сетью виртуальной инфраструктуры).
Также в квадранте появилась компания Sangfor с различными решениями для виртуальных сетей, безопасности, оптимизации и VDI.
Кстати, интересно, что у компании Huawei, присутствующей в рейтинге, также есть свой FusionSphere hypervisor:
О том, как облачные технологии решают проблемы документооборота и меняют подход к его организации, рассказал Антон Аникин — генеральный директор компании «Андок», известной своими решениями по управлению процессами, документами и поручениями на базе системы электронного документооборота (СЭД) DocsVision.
О компании и уникальности облачных услуг
Компания «Андок» — сертифицированный партнер «ДоксВижн» — предлагает решение собственной разработки в рамках услуги СЭД DocsVision доступной в модели SaaS. Решение прошло тестирование сотрудниками «ДоксВижн» и доступно из каталога вендора. Для максимальной безопасности и надежности данных клиентов виртуальная инфраструктура услуги по аренде DocsVision размещена в облаке «ИТ-ГРАД» (IaaS), на базе ЦОД DataSpace уровня Tier III.
В крупных компаниях, где виртуальная инфраструктура является основой всего ИТ, иногда используется продукт VMware NSX для виртуализации и агрегации сетей виртуальных (на базе vSphere) и физических сред. Напомним, что с 3 мая этот продукт также стал доступен в трех изданиях, что позволит приобретать его и небольшим компаниям в базовом издании Standard.
Есть пара интересных постов, на базе которых мы попробуем вкратце описать поведение кластера VMware Virtual SAN в случае, если при развертывании виртуальной машины кластер не способен обеспечить требуемые политики хранилищ (Storage Policies).
1. Обычный кластер Virtual SAN.
Если при развертывании новой ВМ в кластере VSAN невозможно обеспечить требуемые политики хранилищ (например, не хватает места для создания зеркалируемых объектов реплик), а именно:
то виртуальная машина не сможет быть развернута в кластере. Но есть такая настройка Force Provisioning для VM Storage Policy, которая позволяет игнорировать указанные 3 параметра при развертывании новой ВМ в кластере.
Однако надо понимать, что при использовании Force Provisioning происходит не понижение требований кластера к хранилищу виртуальной машины (например, вместо FTT=2 можно было бы проверить FTT=1), а использование следующих параметров:
NumberOfFailuresToTolerate = 0
NumberOfDiskStripesPerObject = 1
FlashReadCacheReservation = 0
То есть нужно просто аллоцировать место под виртуальную машину, совершенно без соблюдения требований к дублированию данных и резервированию кэша.
Но кластер Virtual SAN имеет еще одну специфическую черту - если вы использовали Force Provisioning при недостатке дисковых ресурсов, то когда они освободятся, для хранилища машины будут сделаны реплики дисковых объектов и прочие операции, чтобы она все-таки соответствовала требуемым политикам хранилищ. Администраторам надо иметь эту особенность в виду.
И еще один момент - так как в случае Force Provisioning может храниться только одна копия дисковых объектов, то, например, если при переводе хоста в режим Maintenance Mode случится какой-нибудь сбой с его хранилищем - реально можно потерять эту машину целиком. Делайте бэкап и, по-возможности, не используйте Force Provisioning - старайтесь соблюдать политики хранилищ хотя бы на уровне FTT=1.
2. Растянутый кластер (Stretched Cluster).
В случае растянутого кластера появляется еще один компонент - Witness Appliance, следящий за ситуацией Split Brain, которая может появиться между площадками. Если вырубить этот виртуальный модуль и попытаться включить виртуальную машину или создать новую ВМ, то кластер Virtual SAN (несмотря на то, что он Failed и политика хранилищ не соблюдена) позволит это сделать, правда будет ругаться, что машина не соответствует текущим политикам хранилищ:
В остальном растянутый кластер ведет себя по отношению к Force Provisioning так же, как и обычный.
Среди возможностей решения для создания отказоустойчивых хранилищ VMware Virtual SAN 6.2 мы забыли упомянуть о нововведении в части обработки файлов подкачки - Sparse Swap.
Как вы знаете при создании виртуальной машины в обычной инфраструктуре под нее резервируется файл *.vswp, который равен по размеру объему сконфигурированной оперативной памяти виртуальной машины (либо объему незарезервированной памяти, то есть разнице между сконфигурированной и зарезервированной памятью, если она указана в настройке reservation). Это нужно на случай, когда машине не хватает свободной физической памяти (в ситуации, если уже не спасают техники memory overcommit), и она начинает сбрасывать страницы памяти в своп-файл на диске.
То есть, если вы создали ВМ с оперативной памятью 4 ГБ, то столько же займет и файл подкачки для этой ВМ. А теперь посмотрим на инфраструктуру Virtual SAN: если у вас задан параметр FTT=1, то каждый дисковый объект (в том числе и файл *.vswp) будет задублирован (если у вас mirror-конфигурация).
Теперь посчитаем, сколько места съест своп 100 виртуальных машин, у каждой из которых 4 ГБ оперативной памяти и которые размещены в кластере VMware Virtual SAN с FTT=1 в зеркальной конфигурации:
100 ВМ * 4 ГБ * 2 (FTT равен 1) = 800 ГБ
Да, именно так - почти терабайт только под своп. Кому-то это покажется расточительством, поэтому в Virtual SAN сделали такую штуку, как Sparse Swap. Эта функция позволяет создавать файлы подкачки vswp как тонкие, то есть растущие по мере наполнения данными, диски.
Для того, чтобы включить опцию Sparse Swap, нужно выполнить следующую команду на хосте VMware ESXi:
Давно мы не публиковали таблицу сравнения изданий VMware vSphere, а ведь в версии vSphere 6.0 много что изменилось, поэтому иногда полезно взглянуть на таблицу ниже. Кроме того, помните, что с 30 июня колонок в таблице станет на одну меньше - издание vSphere Enterprise снимается с продаж.
Возможность / Издание VMware vSphere
Hypervisor 6 (бесплатный ESXi)
vSphere Essentials 6
vSphere Essentials Plus 6
vSphere Standard 6
vSphere Enterprise 6.0 - (снимается с продаж 30 июня 2016 года
В конце прошлого года компания Citrix анонсировала скорую доступность новых версий своих платформ для виртуализации и доставки приложений и десктопов - XenApp 7.7 и XenDesktop 7.7. На днях же эти продукты стали доступны для загрузки. О прошлых версиях данных решений мы писали вот тут.
Давайте посмотрим на новые возможности Cirtix XenApp 7.7 и XenDesktop 7.7:
1. Функционал зон (zones).
Эти возможности позволяют оптимизировать типовую инфраструктуру географически распределенных филиалов. Можно использовать одну первичную зону (Primary Zone), на которой есть единая база данных SQL Server (Site Database) и общие компоненты инфраструктуры Citrix, а остальные зоны (Satellite Zones) получают конфигурации из центральной зоны по WAN, но запросы виртуальных ПК к контроллерам исполняются локально.
В данном случае сайт получается один, но в него входит несколько логических зон (например, датацентры в разных городах). Более подробно проблематика рассмотрена на видео ниже, а также в этой и этой статьях.
2. Улучшенные настройки баз данных.
Теперь при создании сайта XenDesktop/XenApp можно указать различные места размещения баз данных для объектов Site, Logging и Monitoring. Также компоненты Delivery Controllers можно создавать не только при создании сайта, но и позже. Более подробная информация приведена вот тут.
3. Функции Application limits.
Теперь можно задавать лимиты для доставляемых с помощью XenApp и XenDesktop приложений. Например, можно ограничить число пользователей одновременно использующих данное приложение (ограничения у него могут быть как технические, так и лицензионные) или ограничить число запущенных экземпляров приложения на пользователя.
4. Улучшенные нотификации об изменении статуса виртуальных машин.
Теперь можно настроить многократные нотификации затронутым виртуальным машинам о следующих событиях, которые произойдут в скором времени:
Апдейт виртуальных машин в Machine Catalog с использованием нового мастер-образа.
Перезагрузка машин в рамках Delivery Group для применения настроек.
Сообщения можно повторять каждые 5 минут за 15 минут до начала выполнения действий.
5. Поддержка API для перемещаемых сессий.
По умолчанию сессия пользователя перемещается с ним от девайса к девайсу, при этом он может пользоваться приложениями на любом устройстве. Теперь обновленный PowerShell SDK позволяет учитывать этот момент при работе через API. Ранее эта фича была экспериментальной, а теперь стала полноценной.
6. Поддержка API для развертывания ВМ из шаблонов.
Теперь виртуальные машины из шаблонов на гипервизор можно развертывать автоматизированно, используя PowerShell SDK.
7. Поддержка обновленных программных компонентов.
Теперь при установке Delivery Controller по умолчанию развертывается SQL Server 2012 Express SP2 (SP1 больше не поддерживается), также обновлены 32 и 64-битные версии Microsoft Visual C++ 2013, 2010 SP1 и 2008 SP1. Citrix Studio или VDA для Windows Desktop OS можно развернуть на Windows 10. Citrix Receiver for Mac и Citrix Receiver for Linux теперь доступны только с сайта Citrix.
Теперь звонки и видео звонки будут намного качественнее и стабильнее за счет обновленного RealTime Optimization Pack.
10. Интеграция с Azure.
Теперь через Machine Creation Services (MCS) можно быстро и просто создать виртуальные машины в облаке Microsoft Azure. Также Citrix Provisioning Services поддерживается онпремизное развертывание виртуальных ПК на основе Windows 10.
11. Запись сессий в VDI-инфраструктуре.
Теперь можно использовать Session Recording for VDI для записи сессии пользователя виртуального ПК (администратор может так записывать обучающее видео для пользователя или, наоборот, попросить его записать возникшую проблему).
Более подробно о фичах нового релиза можно прочитать в этой статье (там же и про объявленные возможности следующей версии Citrix XenApp 7.8 и XenDesktop 7.8).
Не так давно на сайте VMwareArena появилось очередное сравнение VMware vSphere (в издании Enterprise Plus) и Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition, которое включает в себя самую актуальную информацию о возможностях обеих платформ.
Мы адаптировали это сравнение в виде таблицы и представляем вашему вниманию ниже:
Группа возможностей
Возможность
VMware vSphere 6
Enterprise Plus
Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition
Возможности гипервизора
Версия гипервизора
VMware ESXi 6.0
Hyper-V 2012 R2
Максимальное число запущенных виртуальных машин
1024
1024
Максимальное число процессоров (CPU) на хост-сервер
480
320
Число ядер на процессор хоста
Не ограничено
Не ограничено
Максимальное число виртуальных процессоров (vCPU) на хост-сервер
4096
2048
Максимальный объем памяти (RAM) на хост-сервер
6 ТБ
4 ТБ
Техники Memory overcommitment (динамическое перераспределение памяти между машинами)
Memory ballooning
Dynamic Memory
Техники дедупликации страниц памяти
Transparent page sharing
Нет
Поддержка больших страниц памяти (Large Memory Pages)
Да
Да
Управление платформой
Централизованное управление
vCenter Server + vSphere Client + vSphere Web Client, а также виртуальный модуль vCenter Server Appliance (vCSA)
System Center Virtual Machine Manager (SC VMM)
Интеграция с Active Directory
Да, как для vCenter, так и для ESXi-хостов через расширенный механизм SSO
Да (через SC VMM)
Поддержка снапшотов (VM Snapshot)
Да, снапшоты могут быть сделаны и удалены для работающих виртуальных машин
Да, технология Checkpoint, включая функции live export
Управление через браузер (тонкий клиент)
Да, полнофункциональный vSphere Web Client
Ограниченное, через Self Service Portal
Обновления хост-серверов / гипервизора
Да, через VMware Update Manager (VUM), Auto Deploy и CLI
Да - Cluster Aware Updates, Fabric Updates, Management Servers
Управление сторонними гипервизорами
Да, бесплатный аддон Multi-Hypervisor Manager
Да, управление VMware vCenter и Citrix XenCenter поддерживается в SC VMM
Обновление (патчинг) виртуальных машин
Да, через VMware Update Manager (VUM) и vCenter Configuration Manager (vCM)
Да (WSUS, SCCM, VMST)
Режим обслуживания (Maintenance Mode)
Да, горячая миграция ВМ в кластере DRS на другие хосты
Да
Динамическое управление питанием
Да, функции Distributed Power Management в составе DRS
Да, функции Power Optimization в составе Dynamic Optimization
API для решений резервного копирования
Да, vStorage API for Data Protection
Да, VSS API
Шаблоны виртуальных машин (VM Templates)
Да + Multi-site content library
Да, включая шаблоны Gen2
Профили настройки хостов (Host Profiles)
Да, расширенные функции host profiles и интеграция с Auto Deploy
Да, функции Physical Computer Profiles
Решение по миграции физических серверов в виртуальные машины
Да, VMware vCenter Converter
Нет, больше не поддерживается
Горячая миграция виртуальных машин
Да, vMotion между хостами, между датацентрами с разными vCenter, Long Distance vMotion (100 ms RTT), возможна без общего хранилища
Да, возможна без общего хранилища (Shared Nothing), поддержка компрессии и SMB3, неограниченное число одновременных миграций
Горячая миграция хранилищ ВМ
Да, Storage vMotion, возможность указать размещение отдельных виртуальных дисков машины
Да
Профили хранилищ
Да, Storage policy-based management
Да, Storage Classifications
Кластер непрерывной доступности ВМ
Да, Fault Tolerance с поддержкой до 4 процессоров ВМ, поддержка различных типов дисков, технология vLockstep
Нет
Конфигурации виртуальных машин
Виртуальных процессоров на ВМ
128 vCPU
64 vCPU
Память на одну ВМ
4 ТБ
1 ТБ
Последовательных портов (serial ports)
32
Только присоединение к named pipes
Поддержка USB
До 20 на одну машину (версии 1,2 и 3)
Нет (за исключением Enhanced Session Mode)
Горячее добавление устройств
(CPU/Memory/Disk/NIC/PCIe SSD)
Только диск и память (память только, если настроена функция Dynamic memory)
Диски, растущие по мере наполнения данными (thin provisioning)
Да (thin disk и se sparse)
Да, Dynamic disks
Поддержка Boot from USB
Да
Нет
Хранилища на базе локальных дисков серверов
VMware Virtual SAN 6.0 с поддержкой конфигураций All Flash
Storage Spaces, Tiered Storage
Уровни обслуживания для подсистемы ввода-вывода
Да, Storage IO Control (работает и для NFS)
Да, Storage QoS
Поддержка NPIV
Да (для RDM-устройств)
Да (Virtual Fibre Channel)
Поддержка доступа по нескольким путям (multipathing)
Да, включая расширенную поддержку статусов APD и PDL
Да (DSM и SMB Multichannel)
Техники кэширования
Да, vSphere Flash Read Cache
Да, CSV Cache
API для интеграции с хранилищами
Да, широкий спектр VASA+VAAI+VAMP
Да, SMI-S / SMP, ODX, Trim
Поддержка NIC Teaming
Да, до 32 адаптеров
Да
Поддержка Private VLAN
Да
Да
Поддержка Jumbo Frames
Да
Да
Поддержка Network QoS
Да, NetIOC (Network IO Control), DSCP
Да
Поддержка IPv6
Да
Да
Мониторинг трафика
Да, Port mirroring
Да, Port mirroring
Подводя итог, скажем, что нужно смотреть не только на состав функций той или иной платформы виртуализации, но и необходимо изучить, как именно эти функции реализованы, так как не всегда реализация какой-то возможности позволит вам использовать ее в производственной среде ввиду различных ограничений. Кроме того, обязательно нужно смотреть, какие функции предоставляются другими продуктами от данного вендора, и способны ли они дополнить отсутствующие возможности (а также сколько это стоит). В общем, как всегда - дьявол в деталях.
Таги: VMware, vSphere, Hyper-V, Microsoft, Сравнение, ESXi, Windows, Server
Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.
На проходящей сейчас конференции VMworld 2015 компания VMware представила новую версию своего решения для виртуализации рабочих мест предприятия VMware Horizon 6.2. Основные нововведения коснулись продукта VMware Horizon View 6.2, отвечающего за виртуализацию ПК и создание VDI-инфраструктуры компании. Напомним, что о новых возможностях решения VMware Horizon View 6.1 мы писали вот тут.
Давайте посмотрим, что нового появилось в VMware Horizon View 6.2:
1. Поддержка архитектуры Cloud Pod для опубликованных приложений (RDS).
Ранее эти функции были доступны только для виртуальных десктопов, теперь же масштабируемая архитектура облачных блоков доступна и для сервисов RDS. Теперь пространство управления доступом пользователей распространяется на уровне датацентра и между датацентрами, включая сильно географически разделенные площадки.
2. Функции HTML Access for Cloud Pod
Теперь на глобальном уровне можно получить доступ к виртуальному ПК одного из подов прямо по ссылке из браузера с поддержкой HTML 5. Для доступа используется протокол Blast.
3. Стали доступны средства балансировки нагрузки RDSH и интеллектуального размещения сессий.
Теперь для определения загрузки хостов и приложений используются счетчики perfmon, а сессии пользователей балансируются между серверами RDSH на основе этих данных. Безусловно, в Horizon View эти функции еще не такие мощные, как в Cirtix XenApp, но видно, что VMware развивается в этом же направлении.
4. Технология Linked Clones для виртуальных машин с сервисами RDS.
Теперь можно использовать View Composer для создания инфраструктуры связанных клонов (Linked Clones) для ферм RDSH. Это позволяет автоматизировать развертывание этих ферм на хост-серверах VMware ESXi, а также централизованно управлять ими, а самое главное - обновлять на уровне мастер-образа.
Эти функции для сервисов RDS пользователи ждали довольно давно.
5. Технология организации доступа Access Point.
Теперь нет необходимости размещать Windows-машину в DMZ, чтобы организовать безопасный доступ пользователей к их виртуальным ПК. В новой версии используется специализированный защищенный модуль на базе виртуального модуля (Virtual Appliance) Linux SLES 11, который можно выставить в DMZ (установка ПО весьма проста).
6. Поддержка однонаправленных трастов.
Теперь наличие двунаправленного траста не обязательно. Это востребовано в крупных инфраструктурах.
7. Поддержка новой версии технологии NVIDIA GRID 2.0.
Более подробно об этом можно прочитать вот тут. Теперь поддерживается новое поколение карт с процессорами Maxwell. Напомним, что ранее это были карточки NVIDIA K1/K2 (архитектура Keppler).
Новые графические карты M60/6 обещают быть в 2 раза более производительными и позволяют разместить до 128 пользователей, требовательных к производительности графической подсистемы, на одном сервере.
Мы уже писали, что такое режим vDGA, и почему он производительнее vSGA. Теперь режим vDGA Passthrough полностью поддерживается для карточек AMD. Кстати, эти карточки стоят дешевле, чем у NVIDIA, поэтому можно снизить стоимость такой инфраструктуры в определенных сценариях.
9. Поддержка функции 3D-ускорения для приложений RDS.
Теперь публикуемые через RDSH приложения тоже поддерживают режим аппаратного ускорения vDGA и vGPU (пока только для NVIDIA). Это может оказаться очень полезным и выгодным, в том числе по сравнению с виртуальными ПК.
10. Поддержка vGPU для Linux-десктопов.
Теперь не только Windows-пользователи смогут полноценно использовать функции vGPU от NVIDIA.
11. Перенаправление клиентского диска для VDI и RDSH.
Если раньше это перенаправление работало только для Windows, то теперь можно перенаправить диски Win и Mac клиентов, а также в экспериментальном режиме и для Linux.
12. Поддержка ассоциаций типов файлов для RDSH.
Теперь можно просто открыть файл с помощью опубликованного приложения по клику на него, а не искать из предварительно открытого приложения нужный файл.
13. Поддержка разрешения 4К.
Теперь мониторы с мегаразрешениями (3840x2160) полностью поддерживаются для инфраструктуры виртуальных ПК:
14. Поддержка Windows 10.
Теперь виртуальные ПК поддерживают в качестве гостевой ОС Windows 10, а также последние функции Skype.
Доступность VMware Horizon View 6.2 ожидается в ближайшее время.
Компания StarWind, известная своим продуктом StarWind Virtual SAN для создания программных отказоустойчивых хранилищ, выпустила интересный документ о своей журналируемой файловой системе - "LSFS container technical description".
Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
Помимо этого, LSFS имеет следующие полезные функции:
встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут)
поддержка непрерывной дефрагментации (она идет в фоне)
дедупликация данных "на лету" (то есть, перед записью на диск)
улучшения производительности за счет комбинирования операций записи
поддержка overprovisioning
использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов
Некоторые из вас знают компанию VMTurbo, занимающуюся производством решений для резервного копирования виртуальных машин. На днях VMTurbo выпустила бесплатный набор стенсилов Visio, которые можно использовать для рисования схем в своем ЦОД:
Стенсилы включают в себя следующие компоненты:
Host
Cluster
Virtual SAN и физическая сеть зранения данных
Тонкие и обычные хранилища
Различные типы облаков в датацентре: Public, Private, Hybrid и Virtual Datacenter
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
В этом году квадрант выглядит так:
Что мы видим? Два явных лидера, VMware и Microsoft, и кучка лузеров, застенчиво сбившихся в тесный кут нишевых игроков. В хвосте уныло плетется Huawei. Кстати, не удивляйтесь новому названию Odin - это теперь так называется сервис-провайдерский бизнес Parallels (с продуктами Virtuozzo, Plesk и другими).
Ну а вот так выглядел квадрант Gartner в сфере серверной виртуализации в 2014 году:
Oracle тогда еще считали способным что-то сделать, но почему-то в последние пару лет чуваки из Oracle вообще забили на серверную виртуализацию (например, вот наша заметка про VirtualBox, который ждал обновления почти 5 лет).
Ну и для информации - квадранты прошлых лет (когда еще Citrix подавала надежды):
Таким образом, рынок серверной виртуализации, можно сказать, уже окончательно сформировался и его в чем-то можно сравнить с мобильным рынком: VMware - это Apple рынка виртуализации (дорого, но хорошо сделано), а Microsoft - это Google (дешево, но не понятно, куда тыкать и зачем). Хороша ли такая ситуация?
Это даже не совсем документ, а маленькая книга о том, как можно построить инфраструктуру доступа пользователей к виртуальным приложениям и ПК Citrix, размещенных частично или полностью в облаке Amazon EC2, с использованием технологии CloudFormation. Кстати, виртуальные ПК в Citrix XenDesktop можно создавать сразу в облаке с помощью Citrix Studio (технология и процесс подробно описаны тут).
Так вот, первый рассматриваемый в документе сценарий - это гибридная инсталляция, когда большинство сервисов компании работает on-premise (то есть, на собственной площадке), а инфраструктура Amazon используется для масштабирования сервисов, при пиковых нагрузках, а также как резервная инфраструктура в случае сбоя основной площадки. Ключевым компонентом здесь выступает NetScaler CloudBridge Connector, который создает оптимизированный для инфраструктур XenApp и XenDesktop VPN-туннель, а также обслуживает AWS availability zones (независимые зоны облачной инфраструктуры):
Второй вариант развертывания инфраструктуры Citrix XenApp и XenDesktop - это 100%-е использование облачных ресурсов Amazon для компаний, которым не требуется собственная инфраструктура (например, зачем турфирме свои серверы?). Здесь также ключевую роль играет NetScaler CloudBridge Connector, который обслуживает VPN. Все то же самое, но без своего оборудования (но нужен web-фронтэнд и cloud-совместимые приложения):
Доступ пользователей к своим приложениям происходит полностью через веб-клиенты, а администратор (скорее всего, приходящий) обслуживает инфраструктуру Citrix и зоны доступности на стороне сервис-провайдера удаленно через защищенный канал.
На самом деле, за такими штуками будущее, поэтому очень рекомендую этот документ.
Аналитическая компания Gartner опубликовала свой "Magic Quadrant for Cloud Infrastructure as a Service" за 2015 год. По-сути, этот квадрант отражает реальное состояние дел на рынке облачных решений и IaaS (инфраструктура как услуга, то есть аренда виртуальных машин). Конечно же, учитывались и решения PaaS/SaaS, но они на данный момент больше нишевые платформы (кроме Google) и, все-таки, в плане актуальности для пользователей идут вслед за IaaS.
Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:
полнота видения (completeness of vision)
способность реализации (ability to execute)
Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:
Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
Визионеры (visionaries) — поставщики с положительными оценками только по полноте видения.
Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.
Собственно, сам квадрант:
Лидеры тут ожидаемы: с Амазоном все и так понятно, а вот Microsoft за последние пару лет приложила весьма серьезные усилия как в технологическом, так и в маркетинговом плане для продвижения своей платформы Azure, поэтому и попала в двойку лидеров.
Из квадранта нишевых игроков вы, наверняка, знаете только платформу Rackspace. Ну и надо отметить движение VMware в сектор визионеров, но ей очевидно мешает то, что платформа VMware vCloud Air - это все же больше Enterprise-продукт с ограниченной (на данный момент) географией датацентров.
Компания VMware в своем блоге затронула интересную тему - обновление микрокода для процессоров платформ Intel и AMD в гипервизоре VMware ESXi, входящем в состав vSphere. Суть проблемы тут такова - современные процессоры предоставляют возможность обновления своего микрокода при загрузке, что позволяет исправлять сделанные вендором ошибки или устранять проблемные места. Как правило, обновления микрокода идут вместе с апдейтом BIOS, за которые отвечает вендор процессоров (Intel или AMD), а также вендор платформы (HP, Dell и другие).
Между тем, не все производители платформ делают обновления BIOS своевременно, поэтому чтобы получить апдейт микрокода приходится весьма долго ждать, что может быть критичным если ошибка в текущей версии микрокода весьма серьезная. ESXi имеет свой механизм microcode loader, который позволяет накатить обновления микрокода при загрузке в том случае, если вы получили эти обновления от вендора и знаете, что делаете.
Надо сказать, что в VMware vSphere 6.0 обновления микрокода накатываются только при загрузке и только на очень ранней стадии, так как более поздняя загрузка может поменять данные, уже инициализированные загрузившимся VMkernel.
Сама VMware использует тоже не самые последние обновления микрокода процессоров, так как в целях максимальной безопасности накатываются только самые критичные апдейты, а вендоры платформ просят время на тестирование обновлений.
Есть два способа обновить микрокод процессоров в ESXi - через установку VIB-пакета и через обновление файлов-пакетов микрокода на хранилище ESXi. Если вы заглянете в папку /bootbank, то увидите там такие файлы:
uc_amd.b00
uc_intel.b00
Эти файлы и содержат обновления микрокода и идут в VIB-пакете cpu-microcode гипервизора ESXi. Ниже опишем процедуру обновления микрокода для ESXi с помощью обоих методов. Предпочтительный метод - это делать апдейт через VIB-пакет, так как это наиболее безопасно. Также вам потребуется Lunix-машина для манипуляций с микрокодом. Все описанное ниже вы делаете только на свой страх и риск.
После распаковки вы получите файл microcode.dat. Это файл в ASCII-формате, его надо будет преобразовать в бинарный. У AMD в репозитории есть сразу бинарные файлы (3 штуки, все нужные).
2. Делаем бинарный пакет микрокода.
Создаем следующий python-скрипт и называем его intelBlob.py:
#! /usr/bin/python
# Make a raw binary blob from Intel microcode format.
# Requires Python 2.6 or later (including Python 3)
# Usage: intelBlob.py < microcode.dat microcode.bin
import sys
outf = open(sys.argv[1], "wb")
for line in sys.stdin:
if line[0] == '/':
continue
hvals = line.split(',')
for hval in hvals:
if hval == '\n' or hval == '\r\n':
continue
val = int(hval, 16)
for shift in (0, 8, 16, 24):
outf.write(bytearray([(val >> shift) & 0xff]))
Тут все просто. Выполним одну из следующих команд для полученных файлов:
cp uc_intel.gz /bootbank/uc_intel.b00
cp uc_amd.gz /bootbank/uc_amd.b00
Далее можно переходить к шагу 5.
4. Метод создания VIB-пакета и его установки.
Тут нужно использовать утилиту VIB Author, которую можно поставить на Linux-машину (на данный момент утилита идет в RPM-формате, оптимизирована под SuSE Enterprise Linux 11 SP2, который и предлагается использовать). Скачайте файл cpu-microcode.xml и самостоятельно внесите в него изменения касающиеся версии микрокода.
Затем делаем VIB-пакет с помощью следующей команды:
Затем проверьте наличие файлов uc_*.b00, которые вы сделали на шаге 2, в директории /altbootbank.
5. Тестирование.
После перезагрузки хоста ESXi посмотрите в лог /var/log/vmkernel.log на наличие сообщений MicrocodeUpdate. Также можно посмотреть через vish в файлы /hardware/cpu/cpuList/*, в которых где-то в конце будут следующие строчки:
Number of microcode updates:1
Original Revision:0x00000011
Current Revision:0x00000017
Это и означает, что микрокод процессоров у вас обновлен. ESXi обновляет микрокод всех процессоров последовательно. Вы можете проверит это, посмотрев параметр Current Revision.
Также вы можете запретить на хосте любые обновления микрокода, установив опцию microcodeUpdate=FALSE в разделе VMkernel boot. Также по умолчанию запрещено обновление микрокода на более ранние версии (даунгрейд) и на экспериментальные версии. Это можно отключить, используя опцию microcodeUpdateForce=TRUE (однако микрокод большинства процессоров может быть обновлен только при наличии цифровой подписи вендора). Кроме того, чтобы поставить экспериментальный апдейт микрокода, нужно включить опции "debug mode" или "debug interface" в BIOS сервера, после чего полностью перезагрузить его.
Как многие из вас знают, одной из новых возможностей VMware vSphere 6.0 в плане хранилищ стала новая архитектура Virtual Volumes (VVols). VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Тома VVols создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы видите в папке с ВМ, создается отдельный VVol.
Между тем, поскольку технология VVol на сегодняшний день находится в первой своей релизной версии, а продуктов у VMware очень много, на сайте VMware появился список продуктов (в пункте 1 выберите Virtual Volumes), с которыми VVols работают, и тех, где поддержка еще не заявляена.
В целом можно сказать, что внедрять VVols в производственной среде полноценно пока рано, первая версия технологии предназначена скорее для тестирования и пробной эксплуатации с отдельными системами предприятия.
Продукты и технологии, которые поддерживают Virtual Volumes (VVols):
Продукты VMware:
VMware vSphere 6.0.
VMware vRealize Automation 6.2.
VMware Horizon 6.1.
VMware vSphere Replication 6.0
VMware NSX for vSphere 6.x
Возможности платформы VMware vSphere 6.0:
Storage Policy Based Management (SPBM)
Thin Provisioning
Linked Clones
Native Snapshots
View Storage Accelerator also known as Content Based Read Cache (CBRC)
Storage vMotion
vSphere Flash Read Cache
Virtual SAN (VSAN)
vSphere Auto Deploy
High Availability (HA)
vMotion
xvMotion
vSphere Software Development Kit (SDK)
NFS version 3.x
Продукты и технологии, которые НЕ поддерживают Virtual Volumes (VVols):
Продукты VMware:
VMware vRealize Operations Manager 6.x
VMware vCloud Air
VMware Site Recovery Manager 5.x to 6.x
VMware vSphere Data Protection 5.x to 6.x
VMware Data Recovery 2.x
VMware vCloud Director 5.x
Возможности VMware vSphere 6.0:
Storage I/O Control
NFS version 4.1
IPv6
Storage Distributed Resource Scheduler (SDRS)
Fault Tolerance (FT) + SMP-FT
vSphere API for I/O Filtering (VAIO)
Array-based replication
Raw Device Mapping (RDM)
Microsoft Failover Clustering (MSCS)
Отслеживать официальную поддержку VVols со стороны продуктов и технологий VMware можно в специальной KB 2112039. Там же, кстати, находится и полезный FAQ.
Для поиска совместимого с технологией VVols оборудования необходимо использовать VMware Compatibility Guide:
В феврале компания Red Hat сделала два весьма важных анонса. Во-первых, было объявлено о выходе новой версии платформы Red Hat Enterprise Virtualization 3.5 (напомним, что о RHEV версии 3.4 мы писали вот тут).
Список новых возможностей Red Hat Enterprise Virtualization 3.5:
Поддержка до 4 ТБ памяти хост-сервера, до 4 ТБ памяти виртуальной машины (vRAM) и до 160 vCPU на виртуальную машину.
Управление жизненным циклом хост-серверов и их развертыванием посредством интеграции с Red Hat Satellite.
Оптимизация вычислительных мощностей за счет аналитики загрузки в реальном времени и интеграции с oVirt Optimizer. Это позволяет сбалансировать нагрузку на инфраструктуру при вводе в эксплуатацию новых виртуальных машин.
Расширенная поддержка механизма non-uniform memory access (NUMA) - теперь появились такие фичи, как Host NUMA, Guest Pinning и Virtual NUMA. Все это увеличивает производительность за счет более быстрого доступа к нужным областям памяти.
Улучшенный механизм Disaster Recovery за счет оптимизаций и поддержки миграции хранилищ между хранилищами (Storage Domains), что позволит партнерам Red Hat сделать ПО для восстановления после сбоев на уровне площадки на базе технологий и интерфейсов Red Hat.
Лицензия Red Hat Enterprise Linux with Smart Virtualization, которая позволяет развертывать неограниченное количество систем Red Hat Linux.
Подписка Red Hat Cloud Infrastructure, которая включает в себя следующие компоненты: Red Hat CloudForms, Red Hat Satellite, Red Hat Enterprise Linux OpenStack Platform и Red Hat Enterprise Virtualization.
Кроме того, в RHEV 3.5 появились дополнительные функции для интеграции с инфраструктурой Openstack:
Интеграция с компонентами OpenStack Image Service (Glance) и OpenStack Networking (Neutron), доступная как технологическое превью, что позволяет администраторам управлять ресурсами хранения и сети из одной точки для всей инфраструктуры.
Типы инстансов, которые заточены под развертывание виртуальных машин в онпремизной и офпремизной инфраструктуре (облаке).
Более подробно о новых возможностях Red Hat Enterprise Virtualization 3.5 можно почитать здесь.
Во-вторых, на днях была анонсирована платформа Red Hat Enterprise Linux OpenStack Platform 6, которая позволяет построить частное или публичное облако на базе платформы виртуализации Red Hat и открытой архитектуры OpenStack.
Новые возможности Red Hat Enterprise Linux OpenStack Platform 6:
Поддержка IPv6, как для провайдерской сети, так и для сетей клиентов облака. IPv6 можно использовать как для физических сетей, так и для виртуальных роутеров OpenStack Networking (Neutron) в режимах stateless и stateful.
Функции Neutron High Availability, которые позволяют настроить агенты Neutron в режиме "active-active" в целях обеспечения высокой доступности.
Поддержка возможностей технологии Single root I/O virtualization (SR-IOV), а также новый драйвер, который позволяет имплементировать виртуальный коммутатор на стороне сетевой карты сервера, не создавая нагрузку на софт.
Поддержка Multi-LDAP доменов, которые обслуживаются одним узлом со службами идентификации, что упрощает администрирование.
Полная поддержка компонента для создания высокопроизводительных кластеров Sahara (ранее было технологическое превью), который позволяет обрабатывать нагрузки с big data.
Более полная интеграция с блочными устройствами Ceph с новыми возможностями для компонентов OpenStack Compute (Nova) и OpenStack Block Storage (Cinder), включая полную поддержку бездисковых вычислительных узлов и функции почти мгновенного запуска виртуальных машин.
Новые возможности в стадии технологического превью: bare metal provisioning (развертывание узлов без ПО) и поддержка механизма развертывания и обновлений TripleO.
Более подробно о новых функциях Red Hat Enterprise Linux OpenStack Platform 6 можно почитать на этой странице.
Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.
Ранее никто не воспринимал технологию Fault Tolerance всерьез, поскольку она была доступна только для виртуальных машин с одним vCPU, а такие машины, как правило, не делаются для бизнес-критичных приложений, для которых, собственно, технология Fault Tolerance и создавалась.
Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.
Какие преимущества дает VMware FT в vSphere 6.0:
Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
При отказе не разрывается TCP-соединение.
Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.
Что нового в Fault Tolerance 6.0:
Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
Возможность создания снапшотов виртуальных машин, защищенных FT.
Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.
Но по-прежнему, для Fault Tolerance остаются следующие ограничения:
На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
Обязательно потребуется адаптер 10 Gb. Его можно разделять между различными типами трафика средствами NetIOC.
Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.
Как и раньше, технология VMware HA полностью поддерживается:
Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:
Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.
Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.
Многие из вас знают про решение VMware Virtual SAN, представляющее собой средство для создания отказоустойчивых кластеров хранилищ на базе локальных дисков серверов VMware ESXi. Но это всего лишь средство для хранения и обеспечения отказоустойчивости виртуальных машин, а можно ли все пространство хранения в небольшой компании организовать полностью на базе локальных дисков серверов и управлять ими из одной точки?
Компания Nexenta считает, что можно, предлагая пользователям VMware vSphere и VMware Virtual SAN продукт NexentaConnect, позволяющий создавать NFS и SMB ресурсы для размещения данных виртуальной среды и пользователей на локальных дисках хост-серверов.
NexentaConnect это надстройка над Virtual SAN, которая предоставляет следующие возможности централизованно управляемого хранилища:
Экспорт файловых шар по протоколам NFSv3, NFSv4 и SMB 2.1.
Оптимизированный кэш на чтение, размещенный на стороне хост-серверов.
Техники сжатия данных и дедупликации.
Быстрая настройка прямо из vSphere Web Client.
Совместимость с VMware HA и DRS.
Интеграция с доменом AD (поддержка AAA и Kerberos).
Использование преимуществ Virtual SAN.
NexentaConnect состоит из следующих компонентов:
Плагин для vSphere (как для Web Client, так и для vSphere Client).
NexentaConnect Manager – виртуальный модуль (Virtual Appliance) на базе Ubuntu Linux (64 Bit), предоставляющий сервисы управления решением, такие как мониторинг, планировщик событий, база данных, обслуживание операций и т.п.
NexentaConnect Filers – это компоненты, реализующие, собственно, экспорт сетевых шар. Развертываются автоматически по одному на кластер Virtual SAN в момент создания первой общей папки.
Особенности файлеров:
Отдельная файловая система, составленная из виртуальных дисков VMDK по 2 ТБ (для каждой из политик хранения). 2 ТБ - это для того, чтобы обеспечить поддержку со стороны VMware VSAN. Всего можно объединить до 30 VMDK на файлер.
Размер блока 128 КБ.
Развертывание при первом обращении - масштабирование пространства хранения по требованию.
Развертывание как Thin provisioned, так и в режиме заранее аллоцированного пространства.
Параметры файлеров:
ОС Ubuntu Linux (64 Bit)
4 vCPU
16 GB RAM
Минимум 2 виртуальных диска (до 30)
Объем диска до 2 TB
2 сетевых адаптера
Достоинства продукта:
Сжатие данных алгоритмом LZ4 в реальном времени с небольшой нагрузкой на CPU.
До 500 MB/s на компрессию (на ядро).
До 1.5 GB/s на декомпрессию (на ядро).
Дедупликация нулевых блоков.
Дедупликация данных в режиме Tech Preview (полноценная будет во второй версии).
Требования для развертывания NexentaConnect:
VMware vSphere 5.5 или выше
VMware vCenter Server 5.5 U1 или выше (Windows и Linux)
ESXi 5.5 U1 или выше
Кластер VMware vSphere с установленным Virtual SAN
VMware vSphere Web Client
VMware HA (опционально)
Службы каталога (Directory Services - опционально)
Microsoft Windows Active Directory 2008 R2 или выше
VMware vCenter Server 5.5 U1 или выше
DNS
DHCP
NexentaConnect - это еще один способ построить Scale-Out файловый сервер (то есть масштабирующиеся по требованию службы хранения). Например, это востребованной в инфраструктуре виртуальных ПК предприятия, где требуется хранить не только виртуальные машины, но и данные их пользователей.
Об одном из подобных решений - StarWind Virtual SAN - мы регулярно пишем (сейчас это лучшее решение на рынке). Вот тут, например, мы писали про документ о построении инфраструктуры файловых сервисов на базе StarWind.
Добавим, что решение NexentaConnect доступно не только для инфраструктуры VMware vSphere, но и для Citrix XenServer (пока в бете). Больше подробностей о продукте можно узнать вот на этой странице.
На днях компания Red Hat совместно с IBM анонсировала платформу серверной виртуализации Red Hat Enterprise Virtualization (RHEV) для серверов IBM Power Systems (в частности, на базе процессоров POWER8).
Годом ранее компания IBM объявила об инвестициях в размере 1 миллиарда долларов в Linux-системы, на базе которых в том числе работают высокопроизводительные платформы Power Systems. Похоже, эти инвестиции начинают осваивать (в хорошем смысле).
Технология RHEV включает в себя гипервизор (напомним, что это KVM), работающий как на x86 платформе, так и на платформе Power, а также сервер управления Red Hat Enterprise Virtualization management server (на базе обычного x86-сервера). Обеими этими инфраструктурами можно будет управлять из единой консоли.
Обновленное решение Red Hat Enterprise Virtualization для архитектуры POWER8 будет предоставлять следующие возможности:
High Availability – при отказе одного из хостов его виртуальные машины будут перезапущены на другом хосте кластера.
Live Migration and Storage Live Migration – Red Hat Enterprise Virtualization позволит перемещать виртуальные машины с одного хоста на другой, а также между хранилищами без простоя сервисов.
Intelligent Load Balancing – балансировка нагрузки на хосты и хранилища за счет интеллектуального переноса виртуальных машин в автоматическом или ручном режиме.
Centralized Template Management – Red Hat Enterprise Virtualization предоставляет возможность управления шаблонами виртуальных машин, из которых можно развернуть новый сервис несколькими кликами мыши.
Self-Service Portal for Quick Provisioning – пользователи портала самообслуживания могут самостоятельно развернуть новую виртуальную машину по запросу, а администратор платформы сможет контролировать жизненный цикл этих ВМ.
Ранее, в декабре 2014 года, компания Red Hat анонсировала бета-версию своей ОС Red Hat Enterprise Linux 7.1, у которой есть версия для процессоров POWER, работающих в режиме little endian. Более подробно об этом можно прочитать вот тут, тут и тут.
RSS
